Aminet 15/Aminet 15 - Nov 1996.iso/Aminet/text/font/ATEbeta5b.lha/Source-Code/atmDevLog.txt

Text File | 1996-02-25 | 30KB | 559 lines

ATM Development log, started 21 AUG 1994

20 JUN 94
Began playing with OS patches.  Suceeded in patching OpenDiskFont().
source code: diskfontpatch.c

1 JUL 94
Canada's Birthday.  Vacation!

10 AUG 94
Began playing with EXEC messages and Wait().  Unsuccessful in creating
port messaging between two programs.  Will try later.
source code: msgtest1.c and msgtest2.c

21 AUG 94
Succeeded in EXEC message passing.  Also wrote first half of a Text() handler
that manipulates fonts.  Uses an EXEC message port because this kind of
handling must run within an AmigaDOS process.  Initially only prints font
names that have matching .metric files.
source code: port1.c, port2.c, textserver.c

24 SEP 94
Quite a long time... Managed to get a patch/messaging system working
on OpenDiskFont().  Next step: Text()

9 OCT 94
Getting closer.  Encountered a curious problem patching Text().  I can't
patch it the same way as OpenDiskFont().  I'll work on the font renderer
until I can get some support.  However, working patch and server code
for OpenDiskFont() completed.
surce code: ATMserver.c, ATMpatch.c

10 OCT 94 Happy Thanksgving Canada
Will attempt to "merge" MKBmap and ATMServer together, so instead of just
recording font names it generates fonts.  Since I can't patch Text() yet
I'll have it render the whole font upon OpenDiskFont().  Will allow for
single character rendering later.
Also introduced new file format: the .atm file lists PostScript typeface
names for regular, bold, italic, abd bolditalic.  MakeATMFont will allow
for these styles by reading the TextAttr struct passed to it.  I still
have to see about rendering these styled fonts with different names,
to not confuse the operating system.  Question for CATS or whoever takes
over for CATS: can several fonts in memory have the same name & size but
different style flags?
source code: MakeATMFont.c, MakeBMAPFonts.c, MKBmap.c (Adrian Aylward)

22 OCT 94
Success!  Damn, after experimenting with MKBmap and being able to render
a mixture of fonts, standard encoded and font-specific, and after finding
a few post.library quirks, I could write a program that renders fonts and
adds them to the system.
Also sucessfully merged ATMserver and MakeATMFont to get, what appears
to be, a running version of ATM.  With the patch in place I can render
whole fonts and add them to the system for use, but rendering the whole
charset takes 30 seconds on my '030/'882!  Gawd awful slow!  At least
it looks like a working version of Adobe Type Manager!
I remind myself to write Adrian Aylward and chastise him for pukey poor
coding techniques!  I haven't seen so many "gotos" since my days in BASIC
on the Commodore 64!
source code: ATMpatch.c, ATMserverII.c

23 OCT 94
After realizing I'll need to patch a lot more functions to pass data to
the server task, I wrote a general message passer that allocates one port
for each patch.  Using an extended Message struct (ATMMessage) which includes
reply port info, each patch calls ATMSendMsg() with its own ATMMessage
struct, which includes its own reply port pointer.
It's up to that patch to also clear its memory and send a cleanup call
to ATMSendMsg().  However, the command to clean up must be sent through
the patch!  This is handled differently for each patch, eg: NewOpenDiskFont()
will clean up if it sees a TextAttr struct with FPF_REMOVED in its flags.
NewText() will have a similar mechanism, possibly with a funny RastPort
pointer like 0xFF40544C ("ÿATM").  This might work for all!  Hmmm...
Will patch SetSoftStyle() to switch TextFont pointers etc to do neat stuff
with different type styles.  I'll need to patch others but I don't know
which ones until later.
source code: ATMpatchII.c, ATMserver.c

24 OCT 94
Early... damn damn early.  Can't sleep, so I tried editing ATMServerII to
handle the ATMMessage structs as ATMServer does.  Also uncovered a bug in
memory freeing (I was freeing up the fonts OK, but I didn't free the
list entries!  Stupid, stupid, stupid)
Turns out that fixed a problem in the font renderer so it cleaned up
better now.
Performance is unchanged (30 seconds to draw 223 characters... really)
but now it works with the new ATMMessage format.  The cornerstone is now
in place for the rest of ATM.
source code: ATMpatchII.c, ATMserverII.c

11 DEC 94
Talk about asleep for a long time.  Been wrestling with the Text() patch
on and off for six weeks until I realized a basic concept of Amiga
programming: puuting the library base in A6 before making calls!!!!!!!!!
Succeeded in patching Text() and OpenDiskFont() properly now, and I
dumped my port creator routines for good.  Turns out EXEC will re-use
memory chunks if you AllocVec() and FreeVec() chunks of the same size.
This will put a tiny bit more overhead in processing... Oh well... I don't
notice a performance hit on my '030-25 based Amiga 1000.  But it does
cause Enforcer hits in DPaint IV.  What's Electronic Arts doing in there
that no one else seems to do?
I kept a general ATMSendMsg() function to simplify messaging within any
new patches I create.
I'm thinking about combining the server and patch processess into one
executable, but the idea of sending messages to myself seems silly.
Server process can now record used characters and display them when the
server exits.
source code: ATMpatchIII.c, ATMserver.c

19 MAR 95
After wrestling with a dying hard drive and re-building my computer I
managed to complete a re-write of the ATMserver (ATMServerIV).  This will
be the first official Alpha version, as it will serve as the basis for the
Beta 1 I plan.  It also fully works!
Managed to put much of the crucial external variables in a FontNode struct
which will simplify the Text() server function.  Remaining external
variables must remain because post.library and post.h demand it.  I plan
on writing a nice letter to Adrian Aylward about better programming
techniques on the Amiga, provided he has a fixed address.
Added Style search in the FontNode's node name.  Currently the server
supports ta_Style but I did not test this yet.  Many programs just open
the plain style then SetSoftStyle() it.  I will catch this probably in
Beta 2 (possibly in Beta 1 if it works out easily!) by patching
SetSoftStyle(), which will just swap the TextFont pointer in the RastPort
to a designed style.
I also uncovered many nasty bugs in ATMserverIII which seemed to remove
any Enforcer hits caused in DPaint IV.
Oh yes, a possible compiler bug in DICE 3.0: when using an unsigned short in
a structure (pointer-referenced) in a calculation with signed ints, the
short often comes out wrong!  I had to create a temporary signed int and
copy the unsigned short's value to it then calculate using the signed int.
32 hours of hair pulling uncovered this bug.  thphth.  Ever watch a font
get rendered backwards?  How about printing Kickstart ROM data?  neat.
source code: ATMserverIV.c

26 MAR 95
Back on a somewhat regular schedule.  I succeeded in a limited Text()
patch which generates characters as required!  Very impressive except
for one bug: It can only use one font at a time.  If I change typefaces
and change back, it will use the last loaded typeface to fill in
any new characters.  Not bad really.
Managed to generate all of a TextFont except for character data too.
Now the pre-rendering takes 1/3 less time (10 seconds for 223 chars is
still too long in my opinion though.)
I need to work out a safer way of switching typefaces within my server.
The obvious techniques won't work (at least they were obvious to a non-
PostScript programmer...) as they seem to lock the computer, leaving
the server in an infinite loop state and locking the system on the next
OpenDiskFont() or Text() call.  Perhaps a PostScript wizard can help.
source code: ATMserverIVb.c

27 MAR 95
It's amazing what a little imagination can accomplish.  After checking
the PostScript code that actually goes and GETS a typeface (beginning
of MakeATMFont) I copied that code to the beginning of MakeATMChars.
This allowed me to SAFELY change typefaces between calls of Text() and
properly render characters on demand.  YES!!!!!
Current copy of ATMServerIVb has lots of commented-out code so I will
probably clear that out in IVc.  In IVc I can attempt to patch
SetSoftStyle() and swap fonts back and forth, allowing for TRUE bolds
and TRUE italics!  This, and merging ATMPatch, will make up a first
Beta 1 release of ATM for the Amiga.
source code: ATMserverIVb.c

28 MAR 95
Making daily progress.  At this point I'm checking the multiple style
capability of ATMserver.  After discovering a stupid bug in scanf() which
treats the "-" as a white space character, I worked around it to get the
typeface filenames I needed.  Now it can read multiple styles.
I wonder, however, if the Amiga is really capable of handling multiple
styles properly.  According to ARTM it actually lists four fonts with the
same YSize but different styles!  But weird things happen as I switch
between styles; displays get trashed, ARQ draws funny rotating graphics
along window borders, DPaint IV locks up and sometimes will load the wrong
style (If I load Times-Italic first it will use it instead of Times Normal).
It may be how I'm handling the PostScript interpreter, and it's corrupting
areas of memory.  I'm pretty sure I'm checking my memory usage but I need
Mungwall and a serial terminal to know for sure.
source code: ATMserverIVb.c

31 MAR 95
Getting closer.  Uncovered a bug that would cause funny char drawing in
characters above ASCII 127 (using signed chars instead of unsigned chars)
so when I fixed that I could properly draw the extended characters.
It also looks like either intuition or graphics.library can't handle
multiple styles properly.  Certainly intuition can't.  I'll try writing
a better font test program (that uses graphics and diskfont calls instead).
Managed to get Sushi running so I can trap Mungwall hits.  So far I'm not
trashing memory but I noticed some ROM routines will access unused memory
(0xABADCAFE) so I have to wonder how well the system is equipped for
multiple styled fonts.  Worst case I can keep the alternate styles in
RAM but not add them to the font list, then switch them using SetFont() in
any SetSoftStyle() patch I write.
source code: ATMserverIVb.c, ImageTesting.c

1 APR 95
Looks like Intuition's the April Fool.  Either that or there are nasty bugs
in ImageTesting.c.  When I use graphics.library instead of Intuition to
draw text I don't get any Enforcer hits or accesses to unused memory.
And I thought Intuition used graphics.library properly!
SetSoftStyle() patch finshed and rather impressive!  Now the system can
load and swap fonts as needed.  Biggest drawbacks are how Intuition uses
SetSoftStyle() so often and when a program loads a font and SetSoftStyle()'s
it by default (like how DPaint IV does!)  Also fixed a bug; because Intuition
calls SetSoftStyle() and Text() one after another I have to search quickly
in the patches, and get out fast!  The result is the mouse pointer will
freeze for a fraction of a second as Intuition draws menus and Workbench
draws disk windows.  Not too bad on the '030 but I don't want to see it
on a 68000!
I will try to complete the single executable (patches and server in one)
for release as Beta 1.  I still need to write a Text() handler process
and read about Exec Semaphores.  Perhaps the server can share the fontlist
with this handler to speed up searches for non-ATM fonts, but this won't be
complete until Beta 2.
source code: simplewbwindow.c, ATMserverIVc.c, ATMpatchIII.c

2 APR 95
Found a curious bug in DPaint IV.  It likes to ignore any font changes I make
in SetSoftStyle() and probably just SetFont()s the original style back.
It often won't display any style changes until you actually use the font.
But when you use it it still works.
Beta 1 release complete.  Managed to merge the patch and server processes into
one executable and I started distribution.  Time to see how stable the system
REALLY is.  I never had the opportunity to test this program on Release 3
but my testing squad will.  I know EA did some fixes in DPaint IV so maybe
a fixed version will work better.  I also need to see how other programs
(like Excellence!) react.
Plenty of problems I need to fix for Beta 2!  The most obvious is how ATM
handles italic and oblique typefaces.  I will need to pay closer attention
to the bounding box info and position the characters better, so tails won't
get chopped off etc, and to offset the gross spacing of italic chars by
using negative CharKern values.  Beta 2 also needs the auxillary Text()
handler process to eliminate the crazy freezing that Intuition does. But
now that everything is in the same executable I can try performing searches
through the list from the patches (using Exec Semaphores).
source code: ATMbeta1.c

14 APR 95
Managed to introduce two changes.  The first fixes the italic tail-chop
problem by using the Amiga's version of "kerning", using negative charKern
values for certain characters, and by modifying the PostScript chop calls a
bit.  Next I plan to compare the character spacing to that of an established
application (probably PPage 3.0).
The second introduces signal semaphores into ATM.  The patches can now search
the font list themselves, and won't send ATMMessages unless they find fonts
in the list.  Currently only the Text() and SetSoftStyle() patches do so, and
this drastically cuts down on the mouse freezing Intuition causes by calling
SetSoftStyle() and Text() in rapid succession (but noes not completely
eliminate them...) and this consequentially should allow terminal software
to work better.
For Beta 2 release I will compare the spacing info and see if I can improve
on the spacing for italic typefaces.  I may have to resort to the AFMs for
that, as well as for the bounding box info.  Beta 2 documentation should
include typeface adding instructions too.  I won't do a nice installer or
control panel until I'm sure the rendering engine works perfectly, and
only for release in Beta 3.
source code: ATMbeta1b.c

22 APR 95
Added ability to get spacing info and baseline from AFM files.  This and a
bit of magic fixed my gross italic spacing.  I don't have accurate AFMs for
TimesNewRoman so I get a bit of character chopping.  Other Oblique faces
seem to work OK.  Spacing now closely matches Professionl Page's except
the space character seems smaller in the .AFMs.  All this reduces setup
time to four seconds, enough time to scan the AFM and read the typeface
into PostScript VM.
Nice Control Panel won't happen in time for Beta 2 release tomorrow so
I'll settle for the command line for now.  The rendering engine MUST
work perfectly, and I must know what applications really, really, work.
Must send beta 2s to Gold Disk and O.I.C. and perhaps to other "big" Amiga
software houses (if there is such a thing now...)
source code: ATMbeta1c.c

29 APR 95
On tuesday I go for training for Microsoft Windows '95.  Yeah right.
Fixed a couple of nasties.  ATM would not correctly set styles when a
program used the suggested routine in ARKM:Libraries.  Fixed that somewhat
but now I have a problem with DPaint IV again; looks like it calls
OpenFont() to read existing fonts from memory.  When Excellence! left
BoldItalic fonts in memory, DPaint found them.  So it looks like I need
to patch OpenFont() in a similar manner to OpenDiskFont().  Or maybe I
just need to complete the AvailFonts() patch; that should avoid this
particular problem.
It also appears Excellence! doesn't use ALT keys for international
characters.  This isn't my bug however.  Thphth.
sourcecode: ATMbeta1d.c

1 MAY 95
Received a fax from Softwood (makers of Final Copy) and looks like they're
interested in ATM!  Yahhh!
Worked on determining how AvailFonts() really behaves if I follow Commodore's
suggested procedure (call AvailFonts() with a zero buffer, get the size, then
call again to get the font list).

3 MAY 95
Received ten letters from users wanting to beta-test ATM.  Among them are
former C= employees, software houses with connections to ESCOM AG, and
old friends in Winnipeg.  Even one from as far away as The Netherlands.
God, I love The Internet.
AvailFonts() does work with a zero buffer.  Perhaps I can improve the fcn
slightly by reducing how often it goes out to the disk to check for fonts.
I can gather the existing diskfonts, determine how much RAM the header
takes, then fail any calls with a smaller buffer.  I'll still call the
original fcn for RAM fonts and other fonts.  The idea is to insert ATM
TextAttrs into the list, rather than using faked .font files, so apps
know the ATM fonts exist.
I must include AvailFonts() and fix the new DPaint style bug before I
begin distributing Beta 3 to my new testers!

6 MAY 95
Finally corrected the style problem.  I had to make sure ATM works with
programs that follow Commodore's suggested style scheme (OpenDiskFont with
SetSoftStyle's enable bits taken from the new font) and those that
blatantly open the Normal style then SetSoftStyle.  By changing the font
within the Text() patch I could do this and please both kinds of programs.
I still build replacement styles but will change styles just before
drawing characters.
With any luck I can now begin the AvailFonts() patch and prepare a shippable
Beta 3 by tomorrow.  Fixing the style problem gives me new hope.
source code: ATMbeta2.c

7 MAY 95
Began working on the AvailFonts() patch.  I managed to insert ATM TextAttrs
into the list but I find I over-write memory by a few bytes (Mungwall)
and read un-initalized memory too (Enforcer hits reading 0xDEADF00D).
I'll correct this by just inserting TextAttrs (and not names or tags)
into the list, and just have them point to names and tags stored in my
executable's memory space.  That'll avoid the hassles of setting aside
more RAM etc for extraneous data.
However, the ATM fonts look like they show up in the system list.
Excellence! will identify the ATM fonts but curiously it won't open them.
This is most likely because ATM looks for files with the .atm extension
and I omitted that.
Yes, sure enough that was all it was.  Now Excellence! can recognize
fonts that don't have the .font extension in FONTS: (meaning my ATM fonts)
and open them, and use them.  Impressive.
So, I need to double-check my memory usage and clean up the patch a bit,
but Beta 3 release will be reality within this week.
source code: ATMbeta3.c

8 MAY 95
Persistence pays off today.  After discovering stupid errors (like writing
to TextAttr structs instead of AvailFonts structs like I'm SUPPOSED to)
I succeeded in patching AvailFonts().  Now when an app calls AvailFonts()
to get a font list, it gets all the ATM fonts too.
Also fixed a bug in font listing; if there was only one ATM font it would
exit with a bogus error.  Fixed.
ATM Beta 3 release begins today.  Need to write new documentation to reflect
the changes and such, but that will finish by tonight.  Now I need to see
just how perfect the font engine REALLY is.  With any luck, I can begin
work on the user interface and improve PostScript rendering speed, with a
little help from a PostScript guru out there, somewhere.
sourcecode: ATMbeta3.c

13 MAY 95
Released ATM Beta 3.  Discovered a bug of Prefs/Fonts vs DPaint IV; when
I run Prefs/Font to select a font for Workbench, cancel, then run DPaint
to select a font for typing, it GURUs (Processor exception 4).  Weird.
It only happens if I run Prefs/Font.  On a related note, Excellence! will
display multiple entries of the same font, one entry for each font I
preview back in Prefs/Font.  Maybe DPaint's choking on multiple identical
TextAttrs or something.  What is Prefs/Font (or most likely, asl.library)
doing that I'm not accounting for?
Fixed a silly style bug; if a program follows the ARKM:Libraries font
opening rules it might not display any characters!  This is because I
search for styles not present yet.  Fixed.
Picked up a uuEncoder so I can send patches out easier via Internet.
when I get my full access back on The Lounge (now "Dark Delusions")
I can spread the patches.
sourcecode: ATMbeta3a.c

25 MAY 95
Beta test reports beginning to trickle in.  Marcel Offermans from Holland
is the most co-operative, uncovering a few nasty bugs:  ATM fonts showing
up as "fixed width", and the panic exit problem.  I thought the lack of
a FPF_PROPORTIONAL caused the problem with Prefs/Font, to no avail.
At least I have much of a "Beta3b" up and running with these bugs fixed.
All but one anyways... being the panic-exit.
It looks like I need to "reboot" the PostScript interpreter after an error,
because it just doesn't want to operate properly after a PS error.
It's a simple matter, but it's still a pain.  Interactive PS never did that.
Maybe the suggested hwgpost.library corrects that.
Regarding this new library... I E-MAILed the author, who incidenally, wrote
his library based on the source from post.library 1.7.  Apparently he included
some gateways to Display PostScript, which might make ATM useless.  Nahh.
Also introduced a safety feature, which forbids exiting until all ATM fonts
have an opencount of zero.  This should fix a problem Marcel had with one app
that displayed some neato fonts (like "        .font", "#.font", "*.font", etc)
after he exited and restarted ATM.
When I complete Beta 3B I'll begin distributing patches uuEncoded via E-MAIL.
sourcecode: ATMbeta3b.c

31 MAY 95
Completed more patches to ATM Beta3b.  Fixed the "j" chopping and "'",
but still get chopping with Courier at small sizes.  Much better, though.
I'll improve it further.
Time to start spreading this new version around.  I hope I get a response
from SoftWood sometime soon, because I don't work for Seanix anymore.
Thphth.  Will probably return to Winnipeg around 30 JUN 95.
But that won't stop me from finishing ATM.  I have 30 days to find a new
home, possibly find new work in Winnipeg, and lots of extra time to
complete the ATM user interface.
Received original versions of Times, Helvetica, Symbol, and Courier, so
I can fix my spacing bugs.  Turns out I glitched back in MakeATMFont(), so
that's fixed.
sourcecode: ATMbeta3b.c

23 JUN 95
Three weeks later, looking for work.  Managed to complete a makeshift
Shell detachment for ATM (just a Execute("Run "argv[0], 0, 0) to do it) but
it does the job.
Also completed a command receiving mechanism.  For now it just looks for
-exit which causes ATM to unload.  Wrestled with some nasty Enforcer hits
but fixed that.
Got a real Internet address now, so I'll start distributing Beta3d to my
beta testers.
sourcecode: ATMbeta3d.c

28 JUN 95
Searching for work.  Fixed duplicate font name problem with Excellence!
vs Prefs/Font but DPaint still don't work.  Apparently it's a bug with
my copy of DPaint, because DPaint IV AGA doesn't do it according to beta
testers.
SoftWood doesn't have time to test ATM but they might be interested in
marketing it.  The font engine's pretty much bug-proof, now all I need
is a nice way of installing fonts and a nice control panel.  Also picked
up a GUI editor for gadtools.library.  That should simplify the ATM
interface construction considerably.
Plans for releasing a "crippleware" ATM in mind... such crippling
includes: no fancy installer for fonts, force user to use post.library
instead of hwgpost.library, use un-optimized PostScript code.
Full commercial release of ATM should have: capability to use hwgpost,
nice font installer, lots of options via an ATM control panel commodity
(actually not many options; just font install/remove and edit sizes
available to AvailFonts()), and use optimized PS code to make the
commercial version faster.

30 JUN 95
Distributed new ATMbeta3d.  Constructed mailing list on Vancouver Freenet
for further ATM transmissions etc.  Now I have to start handling the
gadtools editor and new GUI I began constructing.  Geez, Intuition isn't
my forte on The Amiga... I need to get working on that.

7 JUL 95 (Happy birthday sister Lou)
Received acknowledgement from comp.binaries.amiga moderator, possibility
that beta3d might not pass the requirements, because they don't like
beta software on the net.  I make sure that 3d worked well and didn't
trash the system though.
Now working on Beta 4.  This Beta introduces many parameters to ATM that
match the options I plan on using in ATM Control Panel:
-Enable/Disable soft styles on ATM type
-Show only ATM typefaces/Show all Amiga & ATM typefaces
-Show/Hide trace messages (same as OPTTRACE)
-Show/Hide all PS command (same as OPTDEBUG)
-Change shown point sizes for apps (Default 72 max, increment 6)
-Rebuild ATM font list in memory (suitable after user adds typefaces)
These options will all work from the command line or from
ATM Control Panel.
Working on separate "Prefs" style program, the ATM Control Panel.  This
will send parameter switches to the ATM main executable.  Look and
feel will be a cross between Amiga Prefs programs and ATM Control Panel
for MS-Windows.
The Beta4 executable is almost finished except for the soft style switch.
I will pass this executable and IFF pictures of the new interface to
beta testers when complete.  I hope Beta 4 will have optimised PS code
before I release it, but I still can't get any help from PS programmers
out there.  Maybe I'll just dump a section of ATM's source onto
comp.lang.postscript and see if I can get help there.
Still to come are legal issues; I never received any acknowledgement
from Adobe Systems regarding their trademark.  I have to wonder if they
even care.
Adobe Type Manager for The Amiga is now one year into its development.
Happy Birthday.
sourcecode: ATMbeta4a.c

19 JUL 95
Thanks to a friend across the Internet in comp.lang.postscript I managed
to whittle down the PS code needed to draw chars in the MakeATMChars()
function.  Drawing the whole charset now only takes 8 seconds, beating out
CG fonts by a whole four seconds!  Thphth!
Also fixed a problem in KS 3.0.  In KS 3.0, OpenDiskFont() does not call
OpenFont() after it loads a font.  So, I have to check the open font
count by traversing the system font list instead.  This works fine.
Still angered by a problem my AvailFonts() patch causes in some apps,
now in FW III it will GURU 8100 FF00 for an unknown reason.  It's for
sure in exec.library.  I need serious CATS help though none exists.
ATM seems to loose 3432 bytes every time it runs.  I am freeing all
memory I allocate.  At first I thought it was because I wasn't
StripFont()ing all ATM fonts before removing them, but that wasn't it.
The one big loss of 3328 bytes is unexplainable!!!  Maybe post.library
did this.
I will release Beta 4B to beta testers this coming morning when Freenet
is quieter.
sourcecode: ATMbeta4b.c

2 AUG 95
A long time between entries indeed.  I included a low memory handler that
patches to Expunge() from diskfont.library, which dumps unopened fonts and
restarts the PS interpreter to clear unused typefaces from PostScript VM.
This version I sent to Amiga Computing Magazine for publication in their
October issue.
Name change: Adobe Systems says No Way Jose to Amiga ATM.  Thphth.  I'll
just call it something different: Amiga Typeface Engine (ATE).  There.
The name will probably change one more time.
I still get requests for ATMbeta3d though.  They're still going out there.
Doenloaded HWGpost beta 6 from AmiNet courtesy of a new co-worker at
In-Line support.  Yes, I'm employed again!  Windows 95 TCP/IP rules
unfortunately.  At least Microsoft got something right.
Losing more memory!  Geez, now it's 12 KB lost.  I think that was post
doing that.  I hope HWG's post will fix this memory loss.  Accomodating
HWG Post will require a PS re-write and re-defining many postlib structs
I use, and it will show up in Beta 5.  Mr HWG (Heinz Wrobel... where did
the "G" come from I wonder...) will probably get the very first copy
of ATE beta 5.
sourcecode: ATEbeta4c.c

9 AUG 95
ATEbeta5 goes to beta testers and Mr Wrobel finds an Enforcer hit... fixed
that.
Beta5a is gone out and Mr Wrobel doesn't like the hacking job I did so
far.  He and one other person suggests the bullet route; where diskfont.lib
calls a rendering engine library to build diskfonts.  This is already done
in type1.library, but this takes 30 seconds to draw an entire font...
After arguing with HWG over this for the past week, I'm beginning to think
of a hybrid plan... Build a rendering library as per type1, and as a user
option build a Text() "daemon" as he calls it, which draws glyphs into the
diskfont as needed, but only as an OPTION, because some apps still don't
call Text() to do their drawing (IE: Video Toaster...)
The only problem I see with this approach is maintaining a fontnode list
externally.  When such a lib builds an "empty" font, It could send a message
to the Text() daemon with the TextFont pointer, then the daemon would
make a FontNode and fill in the TextFont as necessary.  I wonder just
how safe that is... what happens when diskfont.lib wants to expunge a bunch
of fonts while the daemon renders?  And the daemon should still provide
true styles if apps cheat via SetSoftStyle().  Wow... that could prove
quite an undertaking... but then again... my original ATM idea was quite
an undertaking... :)
hwgpost wasn't causing my memory loss it turns out... I need to check
deeper in the lists and find out where all these little bits of RAM
are going to...
I should post this crazy hybrid idea to the rest of the testers and see
what they think.
sourcecode: atebeta5a.c

25 FEB 96
(No ATE development since AUG 95 because of serious employment!)
(sigh) How can I be having too much fun working on Windows NT to be working
on ATE?  Makes about no sense at all.
ATEbeta5b is complete and still has little bits of RAM left over, but
I'm convinced it's not my fault.
In the time between ATEbeta4c and now, I whipped up a Beta4d which removes
post V17 dependancies and released it to comp.binaries.amiga.  I also
posted a message on comp.sys.amiga.announce asking for help, and tomorrow I
will release this source code to those who replied.  My plea for help
showed up in Amiga Report magazine, so maybe one day this will show up on
comp.sources.amiga and Aminet to let others dabble and hack.
To those who dabble and hack: if you finish it, release it, and make it
great!